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L'invention conceme un dispositif et un proc^de permettant de 
5 transmettre des informations entre deux couches d'une pile r£seau. 

Elle s'applique dans le domaine des transmissions avec pertes 
dues au medium de transmission (ex : transmissions sans fil). Elle s'applique 
dans tout systeme de transmission de donnees comportant un mecanisme 
de compression et/ou de decompression d'en-tete. 

10 

La transmission de texte, d'images et de vid6o par Fintermediaire 
de canaux de largeur de bande limitee peut etre affectee de maniere 
importante par des erreurs dues au canal. De tels systemes utilisent 
traditionnellement des codeurs de source pour r6duire la redondance des , 

15 symboles sources et reduire ainsi la quantite d*information a transmettre,*. 
puis des codeurs correcteur d*erreur (ou de canal) pour augmenter la,' 
robustesse de Information transmise sur le canal. Ceci est classiquement < 
realise grace aux standards de compression des codes de longueur variable, . 
(VLC : codes d'Huffman, codes arithmetiques,..) et au codage de canal, a la; 

20 modulation (ensemble d^signe dans la suite sous le terme g^nerique de 
« codeur/decodeur de canal ») pour augmenter la robustesse de la 
transmission sur le canal. Une optimisation plus integree peut §tre obtenue 
en developpant une strategie de codageAtecodage conjoint source-canal. Le 
point clef consiste alors a utiliser de maniere approprtee la redondance de la 

25 source residuelle pour la partie decodage. Cette redondance peut etre 
consider6e comme une forme de protection de canal implicite par le 
d^codeur et etre exploitee de fapon a offrir une capacite de correction 
d'erreur. 

Dans les systemes simples ou le codeur de source 1 et le codeur 
30 de canal 2 (respectivement le d6codeur de source 3 et le d6codeur de canal 
4) sont directement interfaces, les techniques de codage conjoint source- 
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canal peuvent etre implements facilement en echangeant Information 
entre les differents blocs, comme le montre la figure 1. La reference 5 
designe le canal de transmission. 

Du c6te emetteur, les donnees d'information sur la sensibilite de la 
source aux erreurs canal (Source Significance Information ou SSI), peuvent 
etre transmises du codeur de source au codeur de canal afin de permettre 
('application des techniques telles que la protection inegale aux erreurs 
(Unequal Error Protection ou UEP). De facon a adapter les taux de codage 
de source et de codage de canal aux conditions du canal de propagation il 
est aussi utile de fournir Information relative a I'etat du canal (Channel State 
Information ou CSI) au codeur de source et au codeur de canal. Dans le 
domaine des communications numeriques, les methodes traditionnelles de 
decodage appliquees a de tels schemas concatehes, qui permettent des 
gams de codage eleves avec une complete raisonnable et une robustesse 
aux erreurs de transmission, peuvent etre a decisions « dures » (hard) ou a 
decisions « souples » (soft) ou « ponderees » selon que le signal est binaire 
ou analogique. 

Les methodes de decodage a. decisions souples permettent 
d'ameliorer asymptotiquement la performance, en terme d'erreur de 
Plusieurs decibels sur la plupart des canaux. Uinformation souple apparaft 
done comme necessaire dans le domaine des communications modernes 
Afin de permettre le decodage souple, le decodeur interne doit fournir une 
sortie souple au decodeur externe et vice-versa dans le cas d'un decodage 
.teratif. En consequence, du cote recepteur, les sorties souples du canal et 
I'.nformation CSI relative a la fois a ('amplitude de I'evanouissement et au 
bru,t, peuvent etre fournies par le canal au decodeur de canal qui realisera le 
decodage de canal a entree et sortie souples (Soft Input Soft Output ou 
SISO). W 

Par ailleurs, la sortie souple du decodeur de canal ou Information 
de fiabilite du decodeur (Decoder Reliability Information ou DRI) seront 
transmises au decodeur de source qui realisera le decodage de source a 
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entrees souple et foumira une sortie souple pour les informations de source, 
c'est — a-dire ('information a posteriori de la source (Source A posteriori 
information ou SAI) peut etre retransmise au decodeur de canal pour 
effectuer le decodage de canal controle par la source et eventuellement le 
5 decodage iteratif source-canal. 

Toutefois, les codeurs/decodeurs de source et de canal sont 
souvent des dispositifs appartenant a un reseau qui ne peuvent pas 
6changer d'information a cause des couches protocolaires 6 qui les 
separent, comme il est illustre & la figure 2. 
10 Les diverses informations & ^changer entre les d6codeurs doivent 

passer a travers differents niveaux de protocoles r6seau. Toutefois, pour 
rester compatibles avec les recommandations et les implementations [1], de 
telles transmissions ne doivent pas interferer avec Putilisation reguliere du 
reseau. Ceci implique que reformation supplemental soit transmise de 
15 fagon transparente pour la pile protocolaire. 
Modele de la couche OSI 

En pratique, le transfert des informations DRI et SAI entre le 
codeur de source et le codeur de canal consistera a transmettre des valeurs 
quantifies a travers la pile protocolaire. Le probleme de la transparence 
20 devient celui de la transmission de plusieurs entrees binaires (typiquement la 
quantification peut etre faite sur 4 ou 5 bits) au lieu d'une entree binaire 
unique pour chaque bit d'information consider^. Toutefois, comme la 
transmission ne se fait pas directement mais a travers un r6seau, les bits 
d'information qui interessent Tapplication constitue seulement une partie 
25 formant la partie utile de la sequence effectivement 6mise. Comme il est 
illustre a la figure 3, cette sequence 6mise est composee des donnees utiles 
encadr^es par des en-tetes et eventuellement des terminaisons de paquet 
(par exemple des champs de controle tels que les codes cycliques de 
rendondance CRC). 

30 De fagon plus explicite, la transmission de donnees dans le sens 

descendant (du niveau applicatif au niveau acces reseau) a travers la pile 
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protocolaire consistera a chaque transition de couches dans I'execution des 
etapes suivantes [1] : 

• Obtenir la sequence de donnees S u+1 de la couche superieure, 

. Generer I'en-tete ad hoc et eventuellement des champs de controle, 

• Construire la nouvelle sequence de donnees S L en concatenant I'en-tete, 
la sequence S L+1 et le champ de contrdle. Cette etape est eventuellement 
realisee en decoupant la sequence de donnees en plusieurs blocs, ceci 
en tenant compte des limitations eventuelles de taille imposees par le 
protocole. Dans ce dernier cas, les paquets resultants peuvent avoir un 
nombre d'en-tete inferieur mais gardent une constitution similaire. Leur 
evolution est done semblable a celle des paquets non divises. 

De I'autre cote du canal, la transmission montante a travers la pile 
protocolaire consistera a chaque transition de couches a : 

• Obtenir la sequence de donnees S' M de la couche inferieure, decapsuler 
I'en-tete ad hoc (et eventuellement la terminaison de paquet) pour creer 
la sequence S' L . Cette etape est eventuellement realisee en meme temps 
que les requetes de retransmission dans le cas ou la decapsulation 
montre que le flux de donnees etait corrompu, 

• Envoyer la sequence de donnees S' u a la couche superieure si le champ 
de contrdle est correct. 

Solutions pour echanger rinformation a travers les couches de la pile 
protocolaire 

Pour echanger de Information entre les couches sans modifier la 
pile protocolaire, une premiere idee serait de contourner la pile et d'utiliser un 
Hen parallele, en particulier lorsque Ton travaille sur la meme machine 
Certains liens existent en pratique sur un ordinateur entre les couches de 
bas niveau (noyau) et le niveau utilisateur sans passer a travers la pile 
protocolaire. Par exemple, il est possible d'utiliser des drivers dedies avec 
des liens iotel [3] ou des moyens specifiques, par exemple des moyens de 
selection par la methode BPF (Berkeley Packet Filter [4]) qui permettent a la 
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couche applicative de capturer et de filtrer les donnees au niveau des 
liaisons de donnees. 

Toutefois, de telles solutions sont applicables uniquement localement (sur 
une meme machine) et correspondent h un cas ou les donnees ne doivent 
5 pas traverser la pile protocolaire. Elles ne s'appliquent done pas dans le cas 
ou le niveau acces au reseau et le niveau application ne peuvent pas etre 
connectes de cette fagon. 

Une autre solution propos6e permet P6change d'information telle que la 
fiabilite ou information souple a travers un reseau entre le decodeur de 
10 source et le decodeur de canal, en evitant toute interference avec ('utilisation 
standard du reseau et en consequence, en §vitant de redefinir des 
protocoles existants. Presentee dans la reference [5], cette solution de 
« transparence pour le reseau » repose sur la presence de couches 
adaptatives qui permettent de prendre en compte les m6canismes existants 
15 de quality de service QoS, et sur la validation du concept dans un 
environnement Berkeley Software Distribution Linux. Une telle solution a 
Pavantage de pouvoir s'adapter a toute pile protocolaire et a tout reseau. Elle 
impose toutefois de posseder une connaissance parfaite de la pile 
protocolaire au niveau de Pacces reseau et de Papplication. Elle est de plus 
20 assez complexe car elle oblige a decapsuler une fois de plus au niveau de la 
couche physique pour modifier la donnee transmise. 

Ces solutions presentent comme inconvenient majeur de 
necessiter un mecanisme capable de construire ou de modifier le contenu 
des paquets IP valables au niveau physique et au niveau acces reseau. 
25 Compression d'en-tete 

Les liaisons ou communications sans fils sont caracterisees par 
une largeur de bande limitee qui, en pratique, limite le debit d'informations 
emises ou re?ues par un utilisateur. Une telle liaison est vue 
traditionnellement comme un goulot d'etranglement (particulierement pour 
30 des taux d'erreur binaire BER et de trame FER entre 10" 2 et 10" 5 ) pour la 
transmission de donnees car elles conduisent souvent k des retransmissions 
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multiples des donnees, qui aggravant le probleme de retroitesse de la bande 



En consequence, la transmission directe des paquets IP sur des liens 
Physiques sans fil oondui, a un gaspillage impodan. du debit deformation 
b,na,re utile, car en fait les en-.etes des couches RTP, UDP et iP ajouten, 
une charge non negllgeable aux donnees utiles. Cette charge peut etre 
a,semen< reduite car ces en-te.es son, souven. redondan.es, soi, a rinterieur 
de len-tete elle-meme ou avec les en-etes precedents ou suivants .e 
paque,. Dans un con.exte de donnees temps-reel, ou lee paquets doiven, 
etre transmis rapidement, ies charges resultant de Pen-tete peuven, atteindre 
lusqu a plusleurs fois ,a taille des donnees uti.es (jusqu'a un facteur d'environ 
3). Par atlleurs (es mecanismes de correct.cn d'erreurs (Forward Error 
Correction ou FEC, apples a la couche de liaison de donnees MAC son, 
generalemen, choisis pour garanfir un faible taux d'emaurs, ceci pour assurer 
que les paque,s IP ne seron, pas reie.es loraque leur CRC es, verifie dans la 
couche 3 (IP,. Ceci conduit a une pro.ec.ion gicbale du paque, IP au niveau 
le plus sieve, lotsqu'en ,ai, sou, Pen-tete es, particulieremen, sensible aux 
erreurs. Poudan,, les donnees multimedia transmises peuven, souven, 
•olerer un ,aux d'erreur plus eleve grace aux dh,ers mecanismes de 
conecon appliques aux codeurs de source (robus,esse du decodage 
techniques de masquage,..,. • - ■ 

Pour repondre au double object* de la reduction d'en-tete e, de 
laugmemation de la robustesse de ,en-tete pour les liaisons sans fi, un 
nouveau protecole propose par „ETF a ate introdui. dans les versions S e, 6 
de I UMTS par le groupe de travail 3GPP. Ca schema, deeigne sous 
I expression .Compression d'en-tete robuste . (Robus, Header 
Compression ou ROHC, a ete standardise par I'lETF sous ,a reference RFC 
3095 [6]. Le pnnoipa du mecanisme ROHC es, presente a la figure 4 La 
s,andardisa,lon de ,a compression d'en-tete RTP/UDP/IP pour les liaisons 
UMTS est en cours d'etude par I'lETF [7]. 
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La figure 5 permet de mieux illustrer le mecanisme de ROHC. Les 
champs d'en-tete variables IP, UDP, RTP au niveau de la pile protocolaire 
peuvent etre classifies comme suit : 

INFERRED (decrites) : donnees qui peuvent §tre directement d6rivees des 
5 autres champs d'en-tete. Elles ne sont pas transmises, 

STATIC : champs statiques pour Tensemble de transmission de donnees. lis 
sont transmis une seule fois. 

STAT1C-DEF : champs definissant le flux de donnees. lis sont ger^s comme 
la classification STATIC. 
10 STATIC-KNOWN: champs avec des valeurs connues. Us ne sont pas 
transmis. 

CHANGING : champs dont les valeurs changent regulierement, soit de 
maniere aleatoire, soit periodiquement. Us sont transmis en totalite. 
II est ainsi facile de comprendre que le taux de compression obtenu est 
15 assez important et permet d'economiser une « grande » largeur de bande de 
transmission. Cette largeur de bande disponible peut etre utilisee pour mieux , 
prot6ger les en-tetes extremement fragiles, I'ensemble des donnees ou^ 
encore transmettre plus deformation. 

20 L'invention propose notamment une solution permettant T^change 

dlnformations (CSI, SSI, DRI, SAI ) entre le decodeur de source et le 

d6codeur de canal en presence de couches reseaux intermediaires sans 
modification de ces couches. II est alors possible d'utiliser les informations 
6changees pour ameliorer la performance de d6eodage, par exemple en 

25 r6alisant un decodage souple grace aux informations de fiabilite (DRI, SAI). 

Dans la suite de la description, on d^signe par « sens 
descendant » la transmission d'ihformations allant de la couche applicative 
vers la couche accSs reseau et par « sens montant » la transmission 
deformations de la couche acces reseau vers la couche applicative. 

30 L'invention concerne un procede pour echanger des donnees 

entre deux couches d'une pile reseau dans un systeme de transmission de 
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donnees comprenant un mecanisme de compression et de decompression 
den-fete. II est caracterise en ce qu'il comports au moins les stapes 
suivantes : 

• transmettre les paquets initiaux a une etape de 
compression/decompression d'en-tete des paquets, et simultanement 

• transmettre des informations supplemental a une etape de mise en 
forme pour produire/extraire lesdites informations dans des paquets 
supplementaires compatibles avec la pile reseau. 

La transmission des informations circulant du niveau acces reseau 
vers le niveau applicatif, oomporte par exemp.e au moins les etapes 
suivantes : H 

• difference les informations provenant du canal de transmission ou du 
decodeur de canal e* un flux de paquets initiaux et un flux deformations 
supplementaires prealablement quantifies, 

• transmettre .es paquets initiaux codes et les informations 
supplementaires a une etape de decompression d'en-tete, 

• mettre en forme les informations supplementaires quantifies en fonction 
des caracteristiques de la pile protocolaire, 

• transmettre les deux flux ainsi obtenus a une etape de codage de source 
ou a une etape de decodage de source. 

U tr * nsmission ^'informations circulant du niveau applicatif vers " 
le n,veau acces reseau, le precede peut comporter au moins les etapes 
suivantes : K 

• different les paquets provenant de la pile protocolaire en un flux de 
paquets en un flux de paquets initiaux el un flux de 

d informations supplementaires, 

• compressor les en-fetes des paquets initiaux et les transmettre a une 
etape de codage de canal, 

• mettre en forme les informations supplementaires par extraction de 
I ^formation supplemental pour transmission a I'etape de codage canal, 
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o transmettre le flux g6nere par le codage de canal pour Emission vers le 
canal de transmission. 

La transmission d'informations circulant du niveau applicatif vers 
le niveau acc6s reseau, le proc^de comporte par exemple au moins les 
etapes suivantes : 

o differencier les paquets provenant de la pile protocolaire en un flux de 
paquets en un flux de paquets initiaux et un flux de paquets 
d'informations supplementaires, 

• compresser les en-tetes des paquets initiaux et les transmettre a une 
6tape de codage de canal de la couche d'acces, 

» mettre en forme les informations supplementaires par extraction de 
rinformation supplemental pour transmission a l'6tape de decodage 
canal, 

• transmettre le flux g6n6r6 par le codage de canal pour remission sur le 
canal de transmission. 

La transmission d'informations circulant du niveau applicatif vers 
le niveau acc§s reseau, il peut comporter au moins les etapes suivantes : 

• differencier les paquets provenant de la pile protocolaire en un flux de 
paquets en un flux de paquets initiaux et un flux de paquets 
d'informations supplementaires, 

• compresser les en-tetes des paquets initiaux et les transmettre a une 
6tape de codage de canal, 

• mettre en forme les paquets transportant les informations 
supplementaires quantifies par compression d'en-tete en fonction des 
caracteristiques de la pile protocolaire pour transmission a I'etape de 
codage canal, 1 

• transmettre les flux g6ner6s par le codage de canal pour emission sur le 
canal de transmission. 

La presente invention pr6sente notamment les avantages 

suivants : 
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• Elle est compatible avec les reseaux existants IP qui implementent le 
processus de compression d'en-tete. Elle permet de transmettre des 
informations supplemental via le mecanisme de compression et de 
reconstruction d'en-tete en contrepartie d'une augmentation reduite de la 
complexity numerique. 

• Elle peut etre appliquee tout en utilisant les outils de qualite de service 
proposes par IETF pour la pile protocolaire OSI. 

• Elle permet de beneficier de la connaissance des elements disponibles 
au niveau de couches donnees de la pile protocolaire, ces elements 
n'etant habituellement pas transmis. 

• Elle permet notamment : 

• de transmettre des informations supplementaires telles que la fiabilite 
des bits decodes, Information sur I'etat du canal ou de la source 
(statistiques, etc) tout en restart compatible avec les 
recommandations OSI, 

• de localiser I'information necessaire pour generer des en-tetes de 
paquets valables supplementaires et eventuellement de modifier les 
en-tetes des paquets initiaux selon les besoins de I'utilisateur au 
niveau acces reseau, 

• d'extraire I'information supplemental a la couche d'acces reseau et 
de I'utiliser comme donnee utile pour les paquets supplementaires 
valides transmis par un port dedie a un niveau d'application. 

D'autres avantages et caracteristiques de la presente invention 
apparaltront mieux a la lecture de la description qui suit donnee a titre 
Ulustratif et nullement limitatif annexee des figures qui representent : 

• La figure 1 un schema generique de decodage source canal conjoint, 

• La figure 2 un decodage conjoint source canal sur un reseau, 

• La figure 3 un principe de syntaxe pour un paquet genere par une pile 
protocolaire, 
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• La figure 4 le principe du mecanisme ROHC, 

• La figure 5 un exemple de classification des champs d'en-tete pour une 
pile RTP/UDP/IPv4, 

• Les figures 6A et 6B un schema des transmissions d'information du cote 
5 6metteur, 

• Les figures 7A et 7B un schema des transmissions d'information du cote 
recepteur, 

• Les figures 8A et 8B, les ^changes ^information de I'emetteur vers le 
recepteur, 

10 • Les figures 9A et 9B, les §changes d'information du recepteur vers 
P6metteur dans le cas de I'existence d'un canal de retour ou pour une 
transmission bi-directionnelle, 

• La figure 10, le traitement des informations au niveau du module de 
compression/decompression, 

15 • La figure 11 un exemple de generation de champs d'en-tete pour des 
paquets supplementaires dans une pile RTP/UDP/IPv4, 

• La figure 12 un exemple de classification de champs d'en-tete pour des 
paquets originaux dans une pile RTP/UDP/IPv4, 

• Les figures 13 et 14 deux exemples d'extraction d'informations 
20 supplementaires, 

• La figure 15 un exemple d'application de Tinvention dans un contexte de 
transmission sans fil avec compression d'en-tete. 

En resume, reformation suppl6mentaire transmise du niveau 
25 acces reseau au niveau application est placee dans des paquets valides 
generes par le module de compression d'en-tete en parallSle k la 
transmission des donn6es d'origine. Cette integration au sein du processus 
de reconstruction suppose que la syntaxe a utiliser pour construire des 
paquets supplementaires est connue et que la syntaxe des paquets des 
30 donn^es d'origine reconstruits peut etre modiftee en fonction du souhait de 
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l'ut.l,sateur. De maniere similaire, Information supplemental a transmettre 
du n,veau applicatif au niveau acces reseau est transmise via des paquets 
supplementaires qui sont intercepts par le module de 
compression/decompression d'en-tete et qui sont extraits pour etre utilises 
selon les besoins des utilisateurs. 

Le module de compression/decompression 7 est un module 
adapte a mettre en oeuvre un mode de compression d'en-tete et un mode de 
decompression, selon le sens de transmission des informations. Danse sens 
montant, le module de compression/decompression fonctionne en mode 
decompression alors que dans le sens descendant, i. fonctionne en mode de 
compression. 

Les fl9unss M et dtScrivent uri exemple d'echanges 
existants du c6,e emetteur E de la transmission ayant la capacite de 
transmettre des infomiations supplementaires. 

L'architecture de I'emetteur E est similaire a cells decrite a la 
fgure 4, ou le oodeur de source 1 est en liaison avec une partie comprenant 
un module 7 de compression/depression d'en-tete et un codeur 
2/decodeur 3 de canal par I'intermediaire d'una pile protocolaire 6 
comprenant plusieurs couches reseau (i....k). Dans le cas (classique) ou il 
e»ste une vole de retour ou loraque la transmission est bi-directionnelle la 
couche acces du cate emetteur comporte egalement un decodeur 3 de canal 
lu, permanent de recevoir et de decoder les informations de retour, aussl 
appetees observations du canal. 

La figure 6A schematise les ^changes dans le sens « montant 
de la couche acces reseau vers la couche applicative. Le module de 
compression/decompression 7 fonctionne en mode decompression Les 
observations en provenance du canal 5 sont transmises au decodeur de 
canal 3 qui generent un paquet de donntSes tforigine estim«5es P m et un flux 
deformations supplementaires quantifies Supq selon des techniques dont 
un exemple est donne a titre illustratif et nullement limitatif. Cos deux flux 
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sont transmis au module de compression/decompression 7 d'en-tete qui 
applique un traitement standard aux paquets de donnees d'origine et qui 
transforme ['information suppimentaire en paquets supplemental res 
compatibles avec les protocoles transmis aux couches. 
5 Les informations supplementaires contenues dans les paquets sont ensuite 
utilises par exemple pour determiner les parametres du codeur de source 
en fonction de Petat du canal (CSI). 

La figure 6B schematise les ^changes existants dans le sens 
descendant entre le niveau applicatif et le niveau acces reseau. 
10 Les paquets initiaux et les paquets contenant des informations 
supplementaires quantifies au niveau du codeur de source 1 sont transmis 
au module 7 de compression d'en-tete qui les difference par exemple au 
moyen d'un champ d'en-t§te particulier (par exemple le nunriro de port 
UDP). Ce dernier comprime les en-tetes des paquets initiaux. II recupere les. 
15 informations quantifies. Les deux flux ainsi gen^res sont transmis au codeur 
de canal 2 qui les differencie. 

Selon la valeur fix6e du champ d'en-tete en fonction des besoins 
de Tutilisateur, le module de compression d'en-tete recupere les informations 
supplementaires quantifies par extraction des paquets differences pour lea 
20 transmettre directement au codeur de canal, de fagon synchrone ou non 
synchrone avec les paquets initiaux. En effet, dans le cas ou Tinformation 
suppimentaire (par exemple SSI) n'est pas directement lie & des paquets 
initiaux donnes, ceux-ci peuvent §tre absents et seule de I'information 
suppimentaire transmise. Le codeur de canal d£quantifie ces informations 
25 et les utilise alors (par exemple la SSI qui peut permettre de faire de la 
protection inegale des donn£es (Unequal Error Protection ou UEP)), 

Dans le cas ou les informations supplementaires sont detectees 
comme 6tant destinees au decodeur de canal 3 du r6cepteur, les paquets 
contenant Tinformation suppimentaire ont leurs en-tetes compressees par le 
30 module de compression d'en-tete et transmis au codeur de canal 2 pour 
codage et emission sur le canal 5. Les trames 6mises sont alors regues et 
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decodees au recepteur et remontent au niveau du module de 
compression/decompression 7 du recepteur qui reconnaltra les paquets 
destines au decodeur de canal et les lui transmettra. 

Les figures 7A et 7B represented les echanges d'information qui 
se deroulent du cote du recepteur. L'architecture de ce recepteur est 
semblable a celle du recepteur de la figure 4. 

La figure 7A schematise les echanges dans le sens « montant » 
de la couche acces reseau vers la couche applicative. Les observations sont 
recues par le decodeur de canal 3 qui genere les donnees estimees d'origine 
(donnees utiles estimees) et des informations supplemental quantifiees 
(par exemple SAI, DRI, ..) selon des methodes dont un exemple est detaille 
ci-apres. Ces deux flux sont transmis au module de compression d'en-tete 7 
qui genere des paquets contenant des donnees d'origine reconstruites et des 
paquets contenant des informations supplemental. Ces informations etant 
generees typiquement par quantification des informations souples en sortie 
du decodeur 3. 

La figure 7B schematise les echanges d'information dans le sens 
descendant de la couche applicative vers la couche acces reseau Les 
paquets contenant les donnees utiles et les paquets contenant les 
informations supplemental sont transmis au module de compression d'en- 
tete 7 qui genere-des paquets de donnees utiles avec eh-fete Compressees 
et les transmet au codeur de canal 2 pour emission sur le canal 5 (dans le 
cas ou un canal de retour existe ou lorsque la transmission est bi- 
d,rect,onnelle) ainsi que les informations supplemental^ quantifiees qui 
peuvent etre destinees soit au decodeur de canal 3 soit au codeur de canal 2 
s'il existe. 

Les differents mecanismes decrits aux figures 6A et 6B 
s'appliquent respectivement pour les figures 7A et 7B. 
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Les figures 8A et 8B represented les echanges d'information qui 
se d6roulent de Ternetteur vers le recepteur. Uarchitecture de ce recepteur 
est semblable a celle du recepteur de la figure 4. 

La figure 8A schematise les echanges ^information dans le sens 
5 descendant de la couche applicative vers la couche accds r6seau. Les 
paquets contenant les donnees utiles et les paquets contenant les 
informations suppiementaires sont transmis au module de compression d'en- 
tete 7. Celui-ci differencie les paquets suppiementaires et les trouvant 
destines au recepteur leur applique le meme traitement que les paquets de 
10 donnees initiales : en sortie du module de compression d'en-tete 7, on 
obtient done un flux indifferencie & Pentr6e du codeur de canal 2, qui va les 
coder et les transmettre sur le canal 5. ^interpretation des donnees 
suppiementaires est detailiee en Figure 10. 

La figure 8B schematise les echanges d'information dans le sens 
15 montant de la couche acces r6seau vers la couche applicative. On suppose 
ici la presence d'un canal de retour ou une transmission bi-directionnelle, 
done la presence d'un decodeur de canal a Tdmetteur. Les observations 
faites sur le canal sont fournies au decodeur de canal 3 qui les fournit au 
module de decompression. Ce d6codeur est 6galement en mesure de fournir 
20 de reformation supplemental quantifiee (ex. CSI) au module de 
decompression 7. Le module de decompression 7 traite alors les diff6rents 
flux regus. II les differentie et reconstruit les paquets originaux mais 
egalement il genere le cas 6cheant des paquets supplemental res, dont les 
en-tetes seront compressees par le module de compression avant 
25 remission sur le canal vers le recepteur par le codeur de canal 2. 

Les figures 9A et 9B representerit les echanges d'inforrnation qui 
se deroulent du recepteur vers I'emetteur dans le cas ou un canal de retour 
existe ou pour une transmission bi-directionnelle. Uarchitecture de ce 
30 recepteur est semblable k celle du recepteur de la figure 4. 
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Les differents mecanismes decrits aux figures 8A et 8B 
s'appliquent respectivement aux figures 9A et 9B. 

La figure 10 represente le traitement des informations 
supplemental au niveau du module de compression/decompression Ce 
tra.tement est similaire pour I'emetteur ou pour le recepteur. La difference 
etant est le module applicatif vise : codeur de source 1 ou decodeur de 
source 2. Le flux de donnees indifferencie en provenance du canal 5 est 
receptionne et decode par le decodeur de canal 3 et transmis au module 7 
de decompression d'en-tete. Celui-ci differencie les paquets, reconstruit les 
paquets originaux de donnees et selon les cas, transmet les informations 
supplemental (ex: parametres de codage) au codeur de canal 2 ou au 
decodeur de canal- 3 ou genere des paquets supplementaires conteriaht 
Information supplementaire pour la remontee vers la couche application. 

Differentes methodes pour generer les en-tetes, pour modifier les 
paquets de donnees, pour utiliser .'information supplementaire, pour 
quant.f,er les informations supplemental sont explicitees ci-apres. 
Generation des paquets supplementaires au niveau applicatif et 
extraction des paquets supplementaires au niveau acces reseau. 

Le precede selon Invention permet de transmettre ('information 
supplemental du niveau applicatif au niveau acces reseau. En particulier 
(fgure 2) les informations SSI ou SAI peuvent etre exploitees au niveau 
acces reseau. Pour des systemes utilisant la compression d'en-tete, ceci est 
reahsee en generant au niveau applicatif des paquets supplementaires 
contenant I'information supplementaire. Ces paquets peuvent ensuite etre 
transmis via un numero de port dedie. Ces paquets seront transmis sans 
capacite ARQ (automatic repeat request), comme i.s ne seront pas vraiment 
transmis mais intercepts au niveau acces reseau. Au niveau acces reseau le 
module de compression d'en-tete qui traditionnellement effectue ' la 
compression d'en-tete et en consequence a une connaissance de la 
structure des paquets, est modifie pour tester la presence du port dedie • 
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o si la presence du port dedie est trouvee, le module reconnalt le paquet 
supplemental comme tel et I'elimine du flux de donnees. La partie utile 
des donnees est ensuite extraite pour etre utilisee par le decodeur de 
canal (demodulateur, ..) 

• si le port n'est pas un port dedie, le mecanisme classique est applique. 

Generation d'en-tete de paquets valides pour transmettre I'information 
au niveau applicant 

Le mecanisme de compression d'en-tete repose sur le fait que les 
champs d'en-tete variables IP, UDP, RTP dans la pile protocolaire ont une 
syntaxe fixee qui peut §tre facilement reconstruite a partir d'une information 
partielle (typiquement les classes STATIC, STATIC-DEF et CHANGING). 

Sur un principe similaire, le mecanisme de reconstruction par le 
module de compression d'en-tete (fonctionnant en mode decomprssion) peut - 
aussi, en parallele au flux de donnees initiates, reconstruire des paquets 
supplementaires a partir des memes champs d'en-tete. Le principe, illustre 
ci-apres dans le cas d'IPv4, reste naturellement valable dans le cas d'IPv6. 
La figure 11 montre un exemple d'application de ce principe avec 3 classes;, 
de champs d'en-tete : 

RECOPIED (recopie) : correspond aux champs qui sont directement copies 
des paquets de donnees valides. En pratique, ces champs appartiennent 
principalement aux classes STATIC, STATIC-DEF et STATIC-KNOWN mais 
peuvent aussi etre de la classe CHANGING, recopies tels que (par exemple 
('etiquette temporelle ou timestamp), 

INFERRED (deduit): comme dans le precede ROHC process, ces champs 
sont derives directement des autres champs d'en-tete, 
SPECIFICALLY DERIVED (calcule specifiquement) : ces champs sont ceux 
qui sont modifies specialement pour permettre la transmission de 
I'information supplementaire. En particulier : 

• le port de destination qui permettra a I'utilisateur de separer le flux de 
donnees initiates du flux de donnees supplementaires et d'eviter ainsi de 
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perturber le fonctionnement habituel des divers protocoles (RTCP par 
exemple). II est propose de transporter les donnees Initiates et 
hnformation supplementaire sur deux numeros de port distincts (UDP, 

• le cheoksum (le total de contr6.e UDP) qui depend de la partie utile des 
donnees. II doit etre recalcule en fonction des nouvelles parties utiles que 
les paquets supplemental transportent, 

. le numero de sequence qui sera utilise pour identifier la correspondance 
entre le paquet d'origine et le paquet supplementaire, 

• la partie de donnee utile qui sera remplacee par Information 
supplementaire a transmettre. 

RECOPIED = {Ver, Hd.L, TdeS, Identification , R, M, L, offset, TTL, Protocol 
Source- Adress, Destination address (IPv4); Source Port (UDP)~ Ver P E 
CCnt, M, P.Type, Timestamp, Identification Source Synchronisation (SSRC) 
Identification Source Contribution 1* CSRC, Identification Source 
Contribution last) 

INFERRED = { Paquet Length, Checksum (IPv4), Datagram Length (UDP)) 
SPECIFICALLY DERIVED* {Destination Port, checksum, Sequence 
number (UDP)} 

Modification des paquets d'origine eh fonction des beioins de 
I'utilisateur 

II est possible pour I'utilisateur da modifier les en-tetes des 
paquets initiaux. Le precede de reconstruction des en-tetes peut etre adapte 
a des besoins specifiques de transmission avec de I'information 
supplemental Par exemple, le checksum sur la partie utile des donnees 
(UDP checksum) peut etre neutralise par exemple en etant mis a zero Dans 
ce cas, une erreur dans la partie utile des donnees ne condulra pas a una 
elimination de ce paquet dont la partie utile peut etre corrigee grace au 
decodage souple de source. 
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La figure 12 donne un exemple de modification de la classification 
des en-tetes des paquets pour les paquets originaux dans la pile 
RTP/UDP/IPv4. Les caracteres gras, italique, soulign^s, majuscule ou 
minuscule sont respectes entre la figure et la description. 
5 INFERRED = { Paquet Length, Checksum (IPv4), Datagram Length (UDP)} 
STATIC = { Ver, M, L, Protocol (IPv4), P, E (UDP)} 

STAT1C-DEF = {Source Address, Destination address, Source Port, 
Destination Port, Identification Source Synchronisation (SSRC)} 
STATIC-KNOWN = {Hd±. m ft L. Offset Ver) 

10 CHANGING={TdeS. Identification. TTL. CCntM. P.tvoe. Sequence Number. 
Timestamo, Identification Source Contribution 1st CSRC. Identification 
Source Contribution (last).} 
SPECIFICALLY DERIVED^ {checksum (UDPW 

15 De telles modifications ne perturberont pas la transmission de 

reformation : le paquet d'origine est transmis normalement h travers la pile 
protocolaire. Si aucun protocole d'en-tete ne comporte d'erreurs, le paquet 
traverse Tensemble de la pile protocolaire et est regu au niveau applicatif. 
Les paquets RTCP sont ainsi transmis normalement et la qualite de service 

20 (QoS) de la transmission est garantie. 

Extraction de rinformation presente au niveau acces reseau et 
integration de cette information dans les paquets suppiementaires 
valides pour une utilisation au niveau applicatif 

25 Plusieurs cas peuvent §tre envisages pour transmettre 

I'information supplemental, CSI, DRI. Cette information est formatee pour 
etre ins^ree dans les paquets suppiementaires. Ces paquets transportant 
des unites binaires (bits), rinformation doit etre en consequence etre 
transforms en bits. 
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Dans le oas de Pinformation de fiabilite du decodeur ou de toute 
information directemem proportlonnelle aux donnees utiles, on utilise une 
Stape de quantification [2] applique a un nombre donne k de bits, oomme il 
est .llustre a la figure 13 . Information b=(b1, b2, ..bn) reelle est quantifiee 

pour obtenir c=(o aveo bi , (Cl „ c E <*). Les coefficients ci sont 

des elements binaires. 

Dans le cas d'une information relative a I'etat de canal, ou pour 
toute .nformation de taille non proportionne.le aux donnees utiles (et en 
prat.que assez courte), ceci implique un precede de quantification ou de 
moderation sur un nombre k de bits donnes, comme i. est illustre a la figure 
14. U.nformation supplemental est quantifiee selon un modele 

prealablement defini par rutilisateur. La sequence d = ( Cl , c 2 Ck ) ou ci 6 

{0,- 1} est un element binairerfepresenfe done fetat du canal ou toute" 
information semblable. 

De meme, en sortie du codeur/decodeur de source ou 
codeur/decodeur de canal, un quantificateur est dispose pour generer 
I information quantifiee de DRI ou de SSI. 

Cette extraction d'information realisee, les valeurs quantifies sont 
transmises en parallele au flux standard au module de compression d'en-tete 
qui les exploitera. 

DEWVTED' 118 POSSlbl ^ P 6Ur ** Chan, P s ,ntftui6s 'SPECIFICALLY 

Les champs presentes ci-dessus comme etant specialement 
denves sont destines a permettre .e precede de transmission d'information 
supplemental Que.ques exemp.es sont donnes a titre i.lustrati, et 
nullement limitatif : 

• le port de destination peut etre choisi soil de maniere dynamique par 
exemple comme le premier port directement disponible au-dessus du 
port habituellement utilise ou encore etre enregistre comme un port dedie 
pour une telle transmission, (renregistrement des ports dedies definie par 
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I'organisation IANA que Ton peut trouver a I'adresse internet 
http://www.iana.org ). 

© le numero de sequence. Ce numero peut etre ensuite utilise pour 
identifier les paquets initiaux des paquets supplementaires, 

• la partie des donnees utiles peuvent etre derivees comme il a ete detaille 
precedemment en quantifiant I'information supplementaire. Pour 
rinformation de fiabilite, le nombre k peut etre pris egal a 4 ou 5. Le 
premier bit de quantification est par exemple pris egal a la valeur hard 
(estimation de la donnee d'origine) pour une meilleure efficacite. Pour une 
information supplementaire, telle que SSI ou CSI, le format devrait etre 
determine de maniere specifique entre les deux codeurs. Par exemple, 
I'information CSI pourrait etre codee sur 4 niveaux, tres mauvais, 
mauvais, bon, tr6s bon, ceci correspondant a 2 bits d'information. 

Applications possibles 

Le procede selon IMnvention s'applique par exemple pour des 
reseaux a tres faible debit et a bande limitee. Par exemple il est utilise pour 
des transmissions sans fil construites sur un reseau a pile protocolaire avep 
compression d'en-tete tel que un reseau IP/UDP/RTP implementant le 
mecanisme ROHC. 

II s'applique aussi dans des reseaux avec un temps de 
retransmission aller retour (Return Time Trip ou RTT) oD I'utilisation de 
I'information CSI peut aider le comportement du decodeur de source pour 
choisir entre la retransmission demandee ou I'application des techniques 
d'annulation ou encore d'autres traitements des donnees recues, ceci en 
fonction de la probabilite de chance de receyoir correctement I'information a 
la seconde demande. 

Ce proceed peut aussi presenter des avantages lorsque 
I'information sur le flux d'information en provenance de la source tel que 
I'information SSI peut etre fournie par le codeur de source au decodeur du 
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canal. Ceci est par exemple le cas lorsque la protection d'erreur inegale 
(UEP) est realisee au niveau acces reseau. 

La figure 15 represente un exemple de mise en oeuvre de 
Invention dans un contexte combine transmission par fil/transmission sans 
W ou ('information supplemental peut etre utilises par exemple entre 
chaque utilisateur et son point d'entree, chacun etant separe de I'autre par 
un canal de transmission de fiabilite faible. 
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REVENDICATIONS 

1 - Procede pour echanger des donnees entre deux couches d'une pile 
reseau dans un systeme de transmission de donnees comprenant un 
mecanisme de compression et/ou de decompression d'en-tete, caract6rise 
en ce qu'il comporte au moins les etapes suivantes : 

• transmettre les paquets initiaux a une etape de 
compression/decompression d'en-tete des paquets, et simultanement 

• transmettre des informations supplementaires a une etape de mise en 
forme pour produire lesdites informations dans des paquets 
supplemental res compatibles avec la pile reseau. 

2 - Proc6d6 selon la revendication 1 caracterise en ce que la transmission 
des informations circulant du niveau acces reseau vers le niveau applicatif, 
comporte au moins les etapes suivantes : 

• differencier les informations provenant du canal de transmission ou, du 
decodeur de canal en un flux de paquets initiaux et un flux ^informations 
supplementaires prealablement quantifies, 

20 • transmettre les paquets initiaux codes et les informations 
supplementaires a une etape de decompression d'en-tete, 
« mettre en forme les informations supplementaires quantifiees en fonction 
des caracteristiques de la pile protocolaire, 

• transmettre les deux flux ainsi obtenus a une etape de codage source. 

3 - Proc6d6 selon la revendication 1 caract6rise en ce que la transmission 
des informations circulant du niveau acces reseau vers le niveau applicatif, 
comporte au moins les etapes suivantes : 

• differencier les informations provenant du canal de transmission ou du 
30 decodeur de canal en un flux de paquets initiaux et un flux d'informations 

supplementaires prealablement quantifiees, 
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• transmettre les paquets initiaux codes et les informations 
supplSmentaires a una Stape de decompression d'en-tSte, 

• mettre en forme les informations supplementaires quantifies en fonotion 
des caractSristiques de la pile protocolaire, 

• transmettre les deux flux ainsi obtenus a une etape de dScodage souroe. 

4 - ProcSde selon ,a revendioation 1 caraoterise en oe que la transmission 
d,nformat,ons ciroulant du niveau applioatif vers le niveau acoes reseau il 
comporte au moins les Stapes suivantes : 

• diffSrencier les paquets provenant de la pile protocolaire en un flux de 
paquets initiaux et un flux de paquets deformations supplementaires 

• compressor les en-tstes des paquets initiaux e, les transmettre a' une 
- etape-decodagedecariar, " " - - 

• mettre en forme les informations supplementaires par extraction de 
I information supplemental pour transmission a r etape de codage oanal 

• transmettre ,e flux genSrS par le codage de canal pour emission vers ,e 
canal de transmission. 

d 5 inform^ Se '° n r reVSndi0a,i0n 1 ° araCWris6 9 " - '* transmission 
d,nformat,ons croulant du niveau applioatif vers le niveau aoces reseau il 

comports' au nioins les Stapes suivantes ": ~ ' 

• diffSrencier les paquets provenant de la pile protocolaire en un flux de 
paquets initiaux et un flux de paquets d'informations supplSmentaires 

• oompresser les en-,S,es des paquets initiaux e. ,es transmettre a' une 
Stape de codage de canal de la couche d'accSs, 

• mettre en forme les informations supplSmentaires par extraction de 
iTnT SUPPtememaire P ° Ur "ansmission a I'Stape de deoodage 

• transmettre ,e flux gSnSrS par ,e codage de cana, pour ,'Smission sur le 
canal de transmission. 
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6 - Precede selon la revendication 1 caracterise en ce que la transmission 
d'informations circulant du niveau applicatif vers le niveau acces reseau, il 
comporte au moins les §tapes suivantes : 
5 • differencier les paquets provenant de la pile protocolaire en un flux de 

paquets initiaux et un flux de paquets d'informations supplementaires, 
© compresser les en-tetes des paquets initiaux et les transmettre h une 

6tape de codage de canal, 

♦ mettre en forme les paquets transportant les informations 
10^ supplementaires quantifies par compression d'en-tete en fonction des 

caract§ristiques de la pile protocolaire pour transmission & Petape de 
codage canal, 

• transmettre les flux gendres par le codage de canal pour Emission sur le 
canal de transmission. 

15 

7 - Procede selon Tune des revendications 1 a 3 caracteris§ en ce que 
I'etape de decompression consiste a differencier les paquets provenant du 
canal de transmission, reconstruire les paquets originaux de donnees, 
transmettre les informations supplementaires generees au codeur de panal 

20 ou au d§codeur de canal. 

8 - Procede selon Tune des revendications 1 a 3 ou 7 caracteris6 en ce que 
T^tape de decompression consiste a differencier les paquets provenant du 
canal de transmission, reconstruire les paquets originaux de donnees, 

25 generer des paquets supplementaires contenant ['information supplementaire 
et les transmettre vers le niveau applicatif. 
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